home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000011_jfg@bernd.cern.ch _Tue Nov 12 16:44:43 1991.msg < prev    next >
Internet Message Format  |  1994-01-24  |  7KB
  1. Return-Path: <jfg@bernd.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA01728; Tue, 12 Nov 91 16:44:43 GMT+0100
  4. Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
  5.     id AA14518; Tue, 12 Nov 91 16:36:14 +0100
  6. Received: by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
  7.           id AA05532; Tue, 12 Nov 91 16:36:46 -2300
  8. Date: Tue, 12 Nov 91 16:36:46 -2300
  9. From: jfg@bernd.cern.ch (Jean-Francois Groff)
  10. Message-Id: <9111131536.AA05532@bernd.cern.ch>
  11. To: Edward Vielmetti <emv@ox.com>
  12. Cc: www-interest@nxoc01.cern.ch
  13. Subject: Re: some of the stuff on ftp.cs.toronto.edu:/pub/emv/ is in WWW format
  14. References: <m0kgVyd-000Bt4C@cato.aa.ox.com>
  15.  
  16. >>>>> On Mon, 11 Nov 91 02:22:35 -0500, Edward Vielmetti <emv@ox.com> said:
  17.  
  18. Ed> I'm slowly but surely converting the files on ftp.cs.toronto.edu:/pub/emv
  19. Ed> to be in the WWW format.  Right now the stuff in news-archives.README is
  20. Ed> referred to that way, and some of the rest of the things in news-archives too.
  21.  
  22. I just tried to read your news-archives.README with the line-mode
  23. browser through the traditional file: access. First-minute comments :
  24.  
  25. - Currently, any file retrieved through the file: access, local or
  26. remote, is considered a plain text file unless its name ends with
  27. `.html'. As a consequence, the anchors that you have inserted in
  28. news-archives.README are not interpreted by the browser, so they
  29. cannot be jumped to, except by cutting the reference and pasting it to
  30. another www command line. Moreover, the text is just echoed in its
  31. original format, which sadly happens to be double-spaced (CR-LF ?).
  32. The easy fix is to append `.html' to the name of any file that
  33. contains HTML tags, but I understand that it will bother people who
  34. look at your files without www. The upcoming format negociation could
  35. help with this, especially in the case of a dedicated www server that
  36. could pass and possibly negotiate the document type. For anonymous
  37. ftp, the browser should run simple heuristics to try and guess the
  38. type of the file from its name.extension. We'll think about it.
  39.  
  40. Ed> This aftp: tag is new.  I'm not completely happy with the use of
  41. Ed> the file: tag to refer to remote files, since it can lead to
  42. Ed> situations where references are ambiguous depending on whether
  43. Ed> you're dealing with a file on the local system or that same file
  44. Ed> accessed via anonymous FTP on the local system.  Adding an aftp:
  45. Ed> tag should help that.
  46.  
  47. - We agree that the current syntax can be ambiguous, but we want to
  48. keep references to local and remote files in the same format, because
  49. the very notion of a `remote' file should disappear with wide-area
  50. hypertext (remember the new WAN cliche: the network IS the computer).
  51. A less philosophical reason for that is to avoid referring to a
  52. particular retrieval protocol : the reference to the file should be
  53. the same regardless of whether it is retrieved through anonymous ftp
  54. or through the Andrew file system, for instance. Of course, we would
  55. like to introduce X.500 naming in the (more or less) long term.
  56.  
  57. Ed> It's useful (even necessary) to include the anonymous@ bit; there are some
  58. Ed> sites (lib.stat.cmu.edu and research.att.com) with two parallel
  59. Ed> "anonymous FTP" trees that have different user names to get to them;
  60. Ed> a reference to
  61. Ed>     <a href=aftp://netlib@research.att.com:/> </a>
  62. Ed> is quite different than
  63. Ed>     <a href=aftp://anonymous@research.att.com:/> </a>
  64.  
  65. So we want to keep `file:' for both local and remote file, but we must
  66. take into account your other suggestion : allowing for a different
  67. user name. I suggest the following :
  68.  
  69.     * allow an optional `user@' part before a host name.
  70.     * if the user is not specified, make it the current user name
  71.       if the host is the local machine, and `anonymous' otherwise.
  72.       (this avoids the ambiguity that you mentioned)
  73.  
  74. Examples :
  75.     file://ftp.cs.toronto.edu/pub/emv/news-archives.README.html
  76.     file://netlib@research.att.com/
  77.  
  78. Ed> The format //user@host:/filename/ is quite similar to that used by
  79. Ed> ange-ftp, so these references are immediately quite usable by
  80. Ed> existing code.
  81.  
  82. - Currently, a colon after the host name is used to specify an alternate
  83. TCP port number, but a good browser should ignore it if no number is
  84. present. In this way, www can be compatible with ange-ftp syntax.
  85.  
  86. - Your examples make me think of another feature we should add for the
  87. browsers to support them : the ability to display a directory as a
  88. list of references, with maybe the README file (if any) prepended as
  89. introductory text. Currently, on your reference to
  90.     file://pit-manager.mit.edu/pub/usenet/
  91. the browser would try to `get' the directory through ftp and fail. So
  92. I'll add this to the wish-list for the `file:' access method :
  93.  
  94.     * if the address ends with a `/', try `ls' instead of `get'.
  95.     * try to get an appropriate README file. Try those in order :
  96.       README.html, *README*.html, README, *README*, *readme*
  97.     * Display that file if found, then build a list of references
  98.       for all the files contained in the directory.
  99.  
  100. Note that if you supply both a README.html and a traditional README,
  101. you won't have to apologize about `all those funky angle brackets' !
  102.  
  103. - From your news-archives.README :
  104.  
  105.   blah blah blah. Check out
  106.   <a href=aftp://anonymous@pit-manager.mit.edu:/pub/usenet/> </a>
  107.   for lots more information.
  108.  
  109. With the line-mode browser, this will look fine :
  110.  
  111.   blah blah blah. Check out [1] for lots more information.
  112.  
  113. But with any mouse-driven browser (NeXT, X-Windows, emacs, Mac), the
  114. anchor should sit on a piece of text that will serve as a button. With
  115. your current example, your reader would only see :
  116.  
  117.   blah blah blah. Check out for lots more information.
  118.  
  119. with possibly a tiny highlighted space between `out' and `for'. Some
  120. human-readable description of what the anchor points to will do fine.
  121. For instance :
  122.  
  123.   blah blah blah. Check out the
  124.   <a href=file://pit-manager.mit.edu/pub/usenet/> MIT usenet archives
  125.   </a> for lots more information.
  126.  
  127. would yield
  128.  
  129.   Check out the MIT usenet archives[1] for lots more information.
  130.  
  131. or a highlighted `MIT usenet archives' on a mouse-driven browser.
  132. Before that in your README, it would be nice to have an anchor
  133. associated with the `List of periodic informational postings' and to
  134. the archive that you mention. Same for the `news.answers' group (the
  135. `news:' access is implemented in the new architecture. Use this simple
  136. syntax : `<a href=news:news.answers> news.answers </a>'.)
  137.  
  138. - As an aside, the `name=' part of the anchor tag is not necessary in
  139. your context : it is needed if someone wants to make a link TO that
  140. particular anchor, not to the whole document.
  141.  
  142. Ed> I'm also using
  143. Ed>     <a href=wais://wais.domain.org:210/database?>
  144. Ed> in anticipation of that tag being supported, it should be a matter of
  145. Ed> a simple sed or perl script to convert those tags to their current
  146. Ed> preferred format.
  147.  
  148. - Agreed. OK for the `wais:' access.
  149.  
  150. Thank you for all your suggestions. Please continue to provide
  151. feedback as you write more html. We're looking forward to read your
  152. data seamlessly and pave the way for other ftp site managers.
  153.  
  154. --- Jean-Francois